Windows Azure : Access Control Service Usage Scenarios (part 1)

1. Scenario 1: Enterprise Cloud Application

For this scenario, consider a news organization named T-Press Inc., similar to the Associated Press or Reuters. T-Press has a large workforce of journalists and technicians based around the world, investigating, planning, and creating news events. Usually, journalists and technicians can be either employees or contractors, but for the purpose of this scenario, assume that the journalists are employees and the technicians are contractors. Currently, T-Press has a newsroom-management web application called T-Room. T-Room is a globally deployed application and can be used by all journalists and technicians in the field. The T-Room web application is deployed in the cloud and federated with T-Press's Active Directory using Geneva Server. The availability of T-Room in the cloud makes it accessible from anywhere in the world with Internet access. Journalists can view all the T-Press news items, but technicians can view only the news items they're assigned to. The current pain point from an identity-management perspective is as follows.

Technicians are typically hired for a short period of time covering the lifetime of a single new event. After the contract expires, the technician rolls off and may or may not join the workforce for another news event. Currently, whenever a technician is hired, an account is created in T-Press's Active Directory. Due to the short contract periods, identity management has become expensive, and T-Press has decided not to create Active Directory accounts for technicians. Instead, T-Press wants to support any technician's existing digital ID (such as a Windows Live ID or Yahoo ID) to access T-Room. T-Press needs help designing an access control system that can not only support any digital ID but also give immediate access to the T-Room application from anywhere in the world. I recommend that T-Press design a claims-based identity model for T-Room and use ACS to abstract a technician's identity provider from T-Room. The design is illustrated in Figure 1.

Figure 1. Enterprise cloud application scenario

The following steps describe the flow of information from the browser to the T-Room web application:

Step 0: The T-Room system administrator completes all the prerequisites to make ACS work for the T-Room application. In Figure 1, the important steps are establishing trust between the T-Room web application and ACS using a shared key, which is refreshed on a periodic basis; configuring ACS with the supported identity providers (such as ADFS 2.0, Windows LiveID, and Yahoo ID); and defining the mapping between input claims and output claims in the form of rules for employees and contractors. This is where the administrator can define different claims for employees and contractors. The ACS can be configured to process employee authentication with Geneva Server, whereas contractors can be authenticated using external identity providers.

Step 1: When a requestor (employees or contractor) signs into the T-Room web application, the requestor acquires the appropriate authentication token (SAML, SWT, and so on) from the appropriate identity provider. For example, an employee acquires a SAML token from the ADFS 2.0, whereas a contractor may acquire a SAML or SWT from the contractor's identity provider (such as Windows LiveID).

Step 2: The requestor posts the acquired token to ACS for claims mapping.

Step 3: ACS is an important piece of the identity federation orchestration because the SAML or SWT token is sent to ACS to transform input claims to output claims.

Step 4: ACS returns an SWT token to the requestor.

Step 5: The requestor packages the SWT token along with the payload and sends it to the relying party or the T-Room web application.

Step 6: The T-Room application processes these claims in a claims-processing module and determines the level of access the requestor is entitled to. The claims-processing module doesn't depend on any identity provider but only refers to the claims in SWT.

In Figure 1, the introduction of ADFS 2.0 and ACS into T-Press's existing application infrastructure simplifies the identity management of a cloud application like T-Room that supports users from outside of the organization. The T-Press system administrators don't have to manage the identities of technicians in T-Press systems—technicians use their existing identities to access the T-Press application. Administrators can configure input to output claims mappings in ACS as per the business requirements. The T-Press developers only have to focus on building a claims-processing module for ACS-forwarded claims; they don't have to write separate modules for each identity provider as before. Thus, for T-Press, ACS successfully abstracts claims from multiple identity providers into a single coherent view of output claims for the T-Room web application.